reboot ps3

Mathieulh Wrote:Alors d'une part, seuls 7 SPE sont utilisés, non pas 8, sur les 7 un des SPU est reservé non pas a lv1 (l'hypervisor) mais aux "loaders" en l'occurence pour les jeux, appldr

maintenant sache que lv2 (le kernel de la ps3) tourne par dessus lv1, cela signifie que si tu crash lv1, tu crash lv2, la ps3 va alors bipper (deux fois) et effectuer un hard reboot si tel est le cas)
Si un des loaders (isolated spu binary) est crashé, la console va alors crasher completement et seul l'utilisation du back switch pourras la faire redémarrer (le front pannel ne répondra plus)

Les sauvegardes sont vérifiées par lv2, non pas par l'hypervisor.

Le risque de lancer du code ppu non signé sur la console est inexistant, celui-ci étant verifié à la volée au préalable par le loader (la binary qui tourne en background au niveau de l'isolated spu)

Il est impossible en game mode de modifier la portion de la ram allouée à l'extérieur du jeu à cause notamment des LPAR, meme chose pour la lecture de cette dernière.

Compte tenu de la nature même de l'autentification du disque (appellée secure authentication) mettant en cause pas mal de variables telles qu'une clé unique par disque (utilisée en tant que seed), une encryption par secteur, et même un identifiant unique dans le sfo, swapper le disque comme cela est fait, fait figure de science fiction. Enfin sache que dumper un Bluray de jeu via linux ne sert a rien, le contenu du dossier USRDIR sera encrypté, (la clé pour décrypter ce contenu n'est bien sur pas présent dans le bluray copié), ce qui rend la lecture de cette copie d'autant plus impossible.

Il faut savoir que la plupart des secteurs du bluray sont encryptés (il ya une table qui défini quels secteurs ne sont pas encryptés, il est sous entendu pour la console que les secteurs non répertoriés sont encryptés), le probleme est que la décryption est effectuée de manière transparante par lv2, or lorsque l'on est sous otheros/linux, le kernel (généralement un kernel linux) tourne par dessus lv1 (tout comme lv2 le ferai s'il était lancé), comme lv2 n'est pas chargé, la décryption ne se produit pas.

Si vous voulez verifier ma "théorie", faites une image d'un disque via linux, et ouvrez l'EBOOT.BIN avec un éditeur hexadécimal, vous ne verrez que du garbage, alors qu'il est censé y avoir un self header (commençant par SCE en ASCII)

Le seul moyen d'avoir le vrai dump d'un disque est de lancer du code sur lv2, cela sous entend d'avoir un exploit adéquat ou une console de développement.


En gros, cette vidéo est un gros fake

P.S. Hadès c'est un dieu de la mythologie grecque, et ça ne se prononce pas du tout à l'anglaise.

Sur ce, je vous laisse à vos réflexions.

J'aime bien tout ses commentaire qui explique des chose complexe qu'on comprend pas trop^^.
Par contre si on a une PS3 débug on peut ripper le BR.

Pour ceux qui ont visiblement la flem de revenir en page 49 et de relire le tout.

Mathieulh Wrote:Alors d'une part, seuls 7 SPE sont utilisés, non pas 8, sur les 7 un des SPU est reservé non pas a lv1 (l'hypervisor) mais aux "loaders" en l'occurence pour les jeux, appldr

maintenant sache que lv2 (le kernel de la ps3) tourne par dessus lv1, cela signifie que si tu crash lv1, tu crash lv2, la ps3 va alors bipper (deux fois) et effectuer un hard reboot si tel est le cas)
Si un des loaders (isolated spu binary) est crashé, la console va alors crasher completement et seul l'utilisation du back switch pourras la faire redémarrer (le front pannel ne répondra plus)

Les sauvegardes sont vérifiées par lv2, non pas par l'hypervisor.

Le risque de lancer du code ppu non signé sur la console est inexistant, celui-ci étant verifié à la volée au préalable par le loader (la binary qui tourne en background au niveau de l'isolated spu)

Il est impossible en game mode de modifier la portion de la ram allouée à l'extérieur du jeu à cause notamment des LPAR, meme chose pour la lecture de cette dernière.

Compte tenu de la nature même de l'autentification du disque (appellée secure authentication) mettant en cause pas mal de variables telles qu'une clé unique par disque (utilisée en tant que seed), une encryption par secteur, et même un identifiant unique dans le sfo, swapper le disque comme cela est fait, fait figure de science fiction. Enfin sache que dumper un Bluray de jeu via linux ne sert a rien, le contenu du dossier USRDIR sera encrypté, (la clé pour décrypter ce contenu n'est bien sur pas présent dans le bluray copié), ce qui rend la lecture de cette copie d'autant plus impossible.

Il faut savoir que la plupart des secteurs du bluray sont encryptés (il ya une table qui défini quels secteurs ne sont pas encryptés, il est sous entendu pour la console que les secteurs non répertoriés sont encryptés), le probleme est que la décryption est effectuée de manière transparante par lv2, or lorsque l'on est sous otheros/linux, le kernel (généralement un kernel linux) tourne par dessus lv1 (tout comme lv2 le ferai s'il était lancé), comme lv2 n'est pas chargé, la décryption ne se produit pas.

Si vous voulez verifier ma "théorie", faites une image d'un disque via linux, et ouvrez l'EBOOT.BIN avec un éditeur hexadécimal, vous ne verrez que du garbage, alors qu'il est censé y avoir un self header (commençant par SCE en ASCII)

Le seul moyen d'avoir le vrai dump d'un disque est de lancer du code sur lv2, cela sous entend d'avoir un exploit adéquat ou une console de développement.


En gros, cette vidéo est un gros fake

P.S. Hadès c'est un dieu de la mythologie grecque, et ça ne se prononce pas du tout à l'anglaise.

Sur ce, je vous laisse à vos réflexions.

Ceci ne vous suffit pas? Pour rappel MatieuLh est un grand codeur et à étroitement travaillé avec D_A dans le domaine de la PSP, Wii, Iphone.

Si vous n'en faites qu'à votre tête en croyant un jeune lycéen le réveil sera alors brutal.

Comme un "bené" j'ais moi même tester sur une slim 3.15 avec un backup de fifia2008 et ceci ne marche pas. En j'en suis ravis. Pas de hack sur PS3 nous garantie la paix.

bref croyais ce que vous voulais mais je garantie que dans peux de temps la news informant au "fake" arrivera.

xevious78 Wrote:Chui dégouté en +, depuis que mon frère y a touché, mon Motorstorm (acheté 1 mois après sa sortie) ne marche plus ... Quand je lance le jeu : ecran noir et puis ...

Ma Ps3 ne veut même pas reboot les boules

Fr33noX Wrote:

fifou666 Wrote:Ok pourtant je fait exactement la même manip que lulu et je n'est que un beau freeze et quand je lance un jeu (tester avec The club et MW2) la console ne reboot pas

Moi j'ai testé avec "ETERNAL SONOTA" et j'ai une PS3 FAT "CECHL04".

Tu possède laquelle toi ? et toi LULU ?

J'ai une Ps3 Fat 60go en 3.15 et une 40go en 3.10

fifou666 Wrote:Ok pourtant je fait exactement la même manip que lulu et je n'est que un beau freeze et quand je lance un jeu (tester avec The club et MW2) la console ne reboot pas

Moi j'ai testé avec "ETERNAL SONOTA" et j'ai une PS3 FAT "CECHL04".

Tu possède laquelle toi ? et toi LULU ?

Fr33noX Wrote:

fifou666 Wrote:

Ta ps3 doit surement être magique car j'ai tester sur 3 ps3 différente et j'obtiens toujours un freeze et aucun retour sur le XMB !

Tiens nous au courant pour ton backup de Borderlands

Non elle n'est pas magique, mais elle freeze bien avec un retour au XMB dès que j'entre un nouveau jeu certes officiel pour le moment mais bientôt plus

J'essayerai de vous faire une vidéo du freeze et en y insérant un jeux original par la suite pour vous montrer le comportement du XMB.

Ok pourtant je fait exactement la même manip que lulu et je n'est que un beau freeze et quand je lance un jeu (tester avec The club et MW2) la console ne reboot pas

Personnellement après avoir regardé cette vidéo et à voir l'intelligence de notre soit disent hackeur mon avis reste sur 50% fake et 50% je sais pas ...... mais en tout cas il a pas inventé l'eau chaude !

http://www.youtube.com/watch?v=wrTQDfMM ... r_embedded


Perso j'ai tester sur mes 3 ps3

40go 3.10 freeze et nada

40go 3.15 reboot de la ps3 et freeze au logo sony

60go 3.15 freeze sur le cd bleu motorstorm :s


@+ Bonne soirée et une bonne année

Mathieulh Wrote:
Alors d'une part, seuls 7 SPE sont utilisés, non pas 8, sur les 7 un des SPU est reservé non pas a lv1 (l'hypervisor) mais aux "loaders" en l'occurence pour le jeux, appldr

maintenant sache que lv2 (le kernel de la ps3) tourne par dessus lv1, cela signifie que si tu crash lv1, tu crash lv2, la ps3 va alors bipper (deux fois) et effectuer un hard reboot si tel est le cas)
Si un des loaders (isolated spu binary) est crashé, la console va alors crasher completement et seul l'utilisation du back switch pourras la faire redémarrer (le front pannel ne répondra plus)

Les sauvegardes sont vérifiées par lv2, non pas par l'hypervisor.

Le risque de lancer du code ppu non signé sur la console est inexistant, celui-ci étant verifié à la volée au préalable par le loader (la binary qui tourne en background au niveau de l'isolated spu)

Il est impossible en game mode de modifier la portion de la ram allouée à l'extérieur du jeu à cause notamment des LPAR, meme chose pour la lecture de cette dernière.

Compte tenu de la nature même de l'autentification du disque (appellée secure authentication) mettant en cause pas mal de variables telles qu'une clé unique par disque (utilisée en tant que seed), une encryption par secteur, et même un identifiant unique dans le sfo, swapper le disque comme cela est fait, fait figure de science fiction. Enfin sache que dumper un Bluray de jeu via linux ne sert a rien, le contenu du dossier USRDIR sera encrypté, (la clé pour décrypter ce contenu n'est bien sur pas présent dans le bluray copié), ce qui rend la lecture de cette copie d'autant plus impossible.

Il faut savoir que la plupart des secteurs du bluray sont encryptés (il ya une table qui défini quels secteurs ne sont pas encryptés, il est sous entendu pour la console que les secteurs non répertoriés sont encryptés), le probleme est que la décryption est effectuée de manière transparante par lv2, or lorsque l'on est sous otheros/linux, le kernel (généralement un kernel linux) tourne par dessus lv1 (tout comme lv2 le ferai s'il était lancé), comme lv2 n'est pas chargé, la décryption ne se produit pas.

Si vous voulez verifier ma "théorie", faites une image d'un disque via linux, et ouvrez l'EBOOT.BIN avec un éditeur hexadécimal, vous ne verrez que du garbage, alors qu'il est censé y avoir un self header (commençant par SCE en ASCII)

Le seul moyen d'avoir le vrai dump d'un disque est de lancer du code sur lv2, cela sous entend d'avoir un exploit adéquat ou une console de développement.


En gros, cette vidéo est un gros fake

P.S. Hadès c'est un dieu de la mythologie grecque, et ça ne se prononce pas du tout à l'anglaise.

Sur ce, je vous laisse à vos réflexions.

Mon sauveur xD !!! Je n'attendait que sa, une personne qui sais de quoi elle parle !
Alors la chapeau, au moins c'est clair et net !

lululombard Wrote:

sephirothff Wrote:apres avoir visionner la vidéo de plus pres et fait quelques recherches , la méthode utilisée est identique a celle que l'on utilisait pour jouer a des jeux de firmware suppérieur aux débuts de la PS3 , a l'époque on pouvait avec quelques jeux comme motorstorm faire un swap pour lancer des jeux demandant un firmware plus élevé , donc j'emet des doutes sur l'utilité de la sauvegarde . reste a voir si ca marche avec des backups récents ce dont je doute

la ou j'aimerais avoir des infos c'est au niveau de la modification de la sauvegarde , il n'est fait mention nulle part d'une méthode . quels sont les offsets modifié ?

Je savais même pas que MotorStorm servait dans le passé.
La sauvegarde a été modifié juste pour que le SuperVisor n'est rien d'autre à foutre que vérifier la sauvegarde en boucle.

fiftybo Wrote:J'suis totalement contre un lanceur de "Backup" . J'vois pas l'utilité, tout les gens vont télécharger leurs jeux sur internet, comme avec la PSP, la DS, la WII si un est crée.

Un lanceur d'Homebrew oui ce serait génial, mais un luncher d'ISO, ça signifie piratage de jeux a fond ! Surtout avec les débits actuels de 1MO/s, et la fibre optique n'en parlons pas ! Pour les jeux de 25GO ça reviendrais à 7h de téléchargement. J'suis totalement contre.

Je m'occupe pas de ce que les gens vont faire avec ce programme, Hadopi est là (bien que je suis contre) et moi même je trouve 70€ abusé pour un jeu.
En plus, avec ma méthode on peut lancer des HomeBrew gravés sur Blu-Ray si tout se passe bien

Alors d'une part, seuls 7 SPE sont utilisés, non pas 8, sur les 7 un des SPU est reservé non pas a lv1 (l'hypervisor) mais aux "loaders" en l'occurence pour les jeux, appldr

maintenant sache que lv2 (le kernel de la ps3) tourne par dessus lv1, cela signifie que si tu crash lv1, tu crash lv2, la ps3 va alors bipper (deux fois) et effectuer un hard reboot si tel est le cas)
Si un des loaders (isolated spu binary) est crashé, la console va alors crasher completement et seul l'utilisation du back switch pourras la faire redémarrer (le front pannel ne répondra plus)

Les sauvegardes sont vérifiées par lv2, non pas par l'hypervisor.

Le risque de lancer du code ppu non signé sur la console est inexistant, celui-ci étant verifié à la volée au préalable par le loader (la binary qui tourne en background au niveau de l'isolated spu)

Il est impossible en game mode de modifier la portion de la ram allouée à l'extérieur du jeu à cause notamment des LPAR, meme chose pour la lecture de cette dernière.

Compte tenu de la nature même de l'autentification du disque (appellée secure authentication) mettant en cause pas mal de variables telles qu'une clé unique par disque (utilisée en tant que seed), une encryption par secteur, et même un identifiant unique dans le sfo, swapper le disque comme cela est fait, fait figure de science fiction. Enfin sache que dumper un Bluray de jeu via linux ne sert a rien, le contenu du dossier USRDIR sera encrypté, (la clé pour décrypter ce contenu n'est bien sur pas présent dans le bluray copié), ce qui rend la lecture de cette copie d'autant plus impossible.

Il faut savoir que la plupart des secteurs du bluray sont encryptés (il ya une table qui défini quels secteurs ne sont pas encryptés, il est sous entendu pour la console que les secteurs non répertoriés sont encryptés), le probleme est que la décryption est effectuée de manière transparante par lv2, or lorsque l'on est sous otheros/linux, le kernel (généralement un kernel linux) tourne par dessus lv1 (tout comme lv2 le ferai s'il était lancé), comme lv2 n'est pas chargé, la décryption ne se produit pas.

Si vous voulez verifier ma "théorie", faites une image d'un disque via linux, et ouvrez l'EBOOT.BIN avec un éditeur hexadécimal, vous ne verrez que du garbage, alors qu'il est censé y avoir un self header (commençant par SCE en ASCII)

Le seul moyen d'avoir le vrai dump d'un disque est de lancer du code sur lv2, cela sous entend d'avoir un exploit adéquat ou une console de développement.


En gros, cette vidéo est un gros fake

P.S. Hadès c'est un dieu de la mythologie grecque, et ça ne se prononce pas du tout à l'anglaise.

Sur ce, je vous laisse à vos réflexions.

Moi je suis en train de mettre Mobileterminal là ( Désolé j'étais parti jouer a la ps3 )
Darkevin ==> essaie de reboot ton iTouch et redémarre Cydia, Si tu as le problème qu'il se referme c'est que tu n'as pas réglé pour la source
Sinon tu as réussis et alors donne nous ta version.
Car moi même sa me le refait lol ^^